拜Covid-19所賜，去年首次體驗到在家上班的一年。
許多傳產公司當政府下令二級防疫後，光是要讓公司員工因應防疫政策及期間的工作調度，就感到一個頭兩個大。也正是在這段期間，早期就已經導入Scrum開發的資訊業，馬照跑、舞照跳，任務持續進行不掉棒。
其實Scrum開發中的許多重要觀念，在資訊業的開發規範中都有相互對應的部分。例如，在Day 6所提到的Minimum Value Product(MVP)卡片，有別於其他產業，這類MVP卡片的工作內容在資訊業中，多半都須遵循物件導向設計原則SOLID。在開發過程中，擴充性、閱讀性、維護性都需要被考量。而MVP卡片中，所完成的項目，並不侷限在單一專案。時常都是小修一下就可以直接應用到其他的專案。這也是為什麼MVP卡片在Day 12、Day 13特別被Scrum導師(SM)留意，必定要在每期衝刺活動(sprint)中完成的主因。
其次，多人合力完成同一項工作在資訊業也是稀鬆平常的事，因為『程式版本控制』已經是現代程式設計師或工程師具備的DNA。不論是Git或者SVN的版控，都能避免『一個和尚有水喝，三個和尚沒水喝。』的窘境。在Scrum開發中，所有的文件都要能做到滾動式的修正及調整，如同在Day 19所提到的 :

最後，許多企業都抱著導入Scrum開發後，能夠做到『持續整合、持續開發(CI/CD)。』邁向全自動化的崇高目標。
首先，Scrum開發所要改變的是『人與人合作分工的一種方式』，八竿子跟電腦與機器打不著關係。而目前CI/CD在資訊業能夠成功的主因，在於所有的程序歷程，都有完整的日誌(log)記載。每一次的問題歷程，透過日誌(log)可以再加工轉換為可分析及機器學習的大數據，這才是真正全自動化能夠成功的原因。
好啦、好啦。真要攀附一點關係的話，『將日誌加工轉換為可分析及機器學習的大數據』其實是挺適合導入Scrum開發的。
『Scrum開發非常適合這類會滾動式變化的開發項目。』

這次的鐵人賽，就資訊業來分享Scrum開發，其實是相對容易的。不過，一個真正好的開發流程，應該是能推廣到各行各業的。就看看未來SM這個名詞會不會取代PM這個名詞吧。

完賽囉！